DNP3 EIE - Best Practices

Devices > Remote Devices > DNP3 EIE > Best Practices

Best Practices

These best practices are guidelines that CygNet suggests you adopt for the DNP3 EIE and the DNP3 Emerson EIE.

Auto Time Sync

To have CygNet automatically perform a time synchronization whenever the device sets the Need Time flag in the "Internal Indications" data group, set autoTimeSync="true" in the device template file. To have more control over when time synchronizations occur, set autoTimeSync="false", map a point to the Need Time flag (IIN1.4) in the "Internal Indications" data group, and create an MSS task to perform the time sync based on the value of the CygNet point.

Events

The "Events" data group is designed to be used for regular/scheduled device polling.

When the "Events" data group is polled, CygNet point updates are made to any mapped deids in instantiated data groups with a matching ptId.

Example:

Data group "AnalogIn" has a deid using ptId AI.123, which is mapped to a CygNet point.

When events are polled, if there is an event for ptId AI.123, the CygNet point will be updated accordingly.

When the Event Overflow bit (IIN2.3) is set in the "Internal Indications" data group, it means that events are not being polled often enough. The long term solution is to increase the polling schedule for events. As a stop-gap measure, we recommend issuing the "Integrity Poll" UIS command whenever the Event Overflow flag is set. The UIS command for an integrity poll is predefined in the template file. It requests class 1, 2, and 3 events and then the "All Points (Class 0)" (AllPoints) data group.

Device Compliance Levels

The DNP3 protocol requires that devices meet one of four compliance levels. Some devices using the DNP3 EIE or the DNP3 Emerson EIE may be limited in their functions according to the compliance level of the device.

Level 1 — the minimum implementation level for communication between a master station and an Intelligent Electronic Device (IED). Includes simple reads and writes and unsolicited messages.
Level 2 — contains the Level 1 subset plus additional features, such as accepting freeze requests on Binary Counter objects, and parsing read requests for different variation and object combinations, including Binary Input Change objects and Frozen Counter objects. Typical communication is between a master station and a large IED or a small RTU with input and output points local to the device.
Level 3 — contains the Level 2 subset plus additional features, such as outstation processing of a wider range of read requests, enabling and disabling unsolicited responses for Class 1, Class 2, and Class 3 objects only, and assigning and reassigning data objects to classes dynamically. Typical communication is between a master station and a more advanced RTU.
Level 4 — contains the Level 3 subset plus additional features, with typical communication between a master station and a medium size outstation. The additional features in Level 4 are self-address reservation, handling object group 0 (device attributes), double-bit input objects, variations with time (frozen counters and events, and AI events), floating point variations for analog input and output, analog input deadband, and events for binary and analog outputs. At this level, the device must provide an XML version of the device profile document containing both the capabilities and current values set in the device.

Note: Devices can implement features from more advanced levels, but can only claim compliance when all requirements for a level are met. A manufacturer can claim compliance for a level as long as a request is handled correctly. For example, Level 1 compliance includes support for analog output values. If the device does not support them, but correctly returns "object unknown", then the device is Level 1 compliant.

For more specific information about DNP3 Implementation levels, see the appropriate manufacturer-provided documentation.